Time to Drop MBSE?

Model-based systems engineering (MBSE) … model-driven development (MDD) … model-based engineering (MBE) … model-centric engineering (MCE) … digital thread … digital tapestry. In Romeo and Juliet, Shakespeare famously wrote “a rose by any other name would smell as sweet.” In the case of systems engineering and the drive to models, the scent is clear but not necessarily sweet. The terminology has become muddied, overloaded, and confused with new variants proposed every few months. Is it time to simply drop MBSE?

Does the term “MBSE” clarify or confuse?

When looking at titles, abstracts, and primary themes, the MBSE-oriented content at the 2016 INCOSE International Symposium approached 25% of the total content. During the symposium, one critique was voiced over and over. Given that the community has been obsessed with the transformation to MBSE for the past decade, why are people still embedding a “what is MBSE” explanation in every presentation? Though I understand the critique and certainly wish it wasn’t necessary, the reality is that the term “MBSE” miscommunicates and confuses more than it helps.

To be honest, I cannot recall how the industry locked on to this language. The Model Driven Systems Design Working Group in INCOSE made many contributions to data exchange standards (such as AP233), approaches (such as Object-Oriented Systems Engineering Method, or OOSEM), and the emergence of the SysML profile. Unfortunately, “model” as used in this context was an ambiguous and fundamentally flawed choice. I can’t rewrite history and say I would have offered a better term, but the meaning of “model” is extremely broad – particularly in engineering. The systems community has carefully avoided ever defining the term. According to businessdictionary.com, a model is “a graphical, mathematical (symbolic), physical, or verbal representation or simplified version of a concept, phenomenon, relationship, structure, system, or an aspect of the real world.” Other, more technical definitions such as those in DoD5000, mirror these concepts. Given this, every simplified representation short of the system itself becomes a model – a document, a diagram, a simulation, and more. When so many representations of information and knowledge qualify as a model, what does MBSE really mean?

Myths and word choice

This simple word choice and the way we have chosen to communicate the transformation over the past decade have given rise to countless myths:

• If MBSE is new and transformative, models must be new to systems engineering. In reality, models are the way systems engineers have always conceptualized and worked. Models are the foundation of communication by which the sender crafts her description and the receiver understands the message. The model simply resided in the head of each engineer on the systems team. The engineering team then strove to align those mental models to achieve shared understanding expressed via specification.

• Because the emphasis on MBSE emerged at the same time as the Systems Modeling Language (SysML), that means MBSE equals SysML. While SysML is a fine representation set for certain types of system engineering endeavors, this misconception has created a great deal of fear, uncertainty, and doubt in the journey. You should tune your representations to the problem at hand and the corresponding audience, not envision the world as a series of nails simply because you have a hammer. But in doing this, do not mistake SysML as the equivalent of MBSE.

• Diagrams must be models. Tied in part to the confusion with SysML but also tied to the fact that many engineers think and represent information graphically, this myth is pervasive. While diagrams satisfy the dictionary definition of a “model,” treating them as systems models serves us poorly on our journey. A diagram is simply a graphical representation of a subset of knowledge represented in a specific notation to communicate a specific aspect to a specific audience. Similarly, a specification is a structured (highly textual) representation that puts specific information about the system of interest in specific sections so that the reader knows how to interpret it. Neither adequately model a system with its dependence on integration and completeness for its essential nature.

• The long-standing practice of modeling and simulation is essential to the rigor of systems engineering, so that must be MBSE. Not really. Modeling and simulation is using models in systems engineering, not model-based systems engineering. It is highly valuable, but it is not the same thing.

Just what is MBSE?

So if these are not MBSE, what is? When I frame MBSE (and I always pause at the start of any class or presentation in order to provide a clear frame of reference), I describe the intent and the journey. MBSE is about making system-descriptive and analytical models explicit, coherent, and consistent. It is a natural evolution from low-fidelity representations in documents to higher-fidelity, richer representations. It is about improved granularity of knowledge capture for management, analysis, and learning. When done right, it recognizes one descriptive architectural model connecting multiple analytical models. Framed this way, model-based systems engineering may lose some of the mystique and complexity that many wish to invoke on its behalf, but it becomes far more accessible and deployable. In fact, it makes it possible to view MBSE as part of a continuous evolution in approach and knowledge representation, an evolution that offers transformative results when done well.

Where does this leave us? “Model-based” was a misleading misnomer when originally adopted. Rather than clarifying this, we have further compounded the problem by failing to define what we mean by “models” and MBSE over the years. At this point, I believe the language is damaged beyond repair and does more harm than good. It has been a wonderful call to action to look at how we represent knowledge and communicate. The dialog it has stimulated has helped us move the systems engineering practice forward, as individual organizations and as a greater community. However, we talk past one another far more than we realize because we use the same language, mean different things, and are encumbered by critical misconceptions.

Alternative labels

So is there a better answer? Many different labels exist, and many others have been proposed.

• Model-driven design is a term from the software community that represents many of the same concepts and challenges focused within the software domain. Let us continue to use this with its software connotations, recognizing that when someone refers to MDD, they are often speaking of software patterns, Java, and other items below the systems level.

• Model-based engineering is often confused with model-based systems engineering, but it is a larger concept. Model-based engineering looks at connecting the entire engineering lifecycle, moving from ambiguity in human handoff to digital precision in the coordination of high-fidelity models. Done right, model-based systems engineering enables MBE within an organization. Done right, MBE promises tremendous gains in quality, time to market, cost reduction, design responsiveness, agility, and more. Regardless, MBE exists at the engineering lifecycle level and is not a replacement for MBSE.

• Model-centric engineering attempts to recognize that engineering is fundamentally model-based and therefore focuses on centricity. It operates at the whole-of-engineering level as an alternative term for MBE. Unfortunately, we are still challenged by the ambiguity of “model.” Also, model-centric engineering focuses on our methods and techniques rather than the outcome we seek and the value we wish to deliver. I would rather our centricity be customer-focused or needs-focused rather than tool or process focused.

A better terminology

The terminology that best represents the concepts is “digital thread” and “digital tapestry.” Digital thread captures the spirit of model-based engineering, specifically emphasizing the digital environment. Digital tapestry reflects that it is not just a one dimensional linear thread but a richer interweaving of concepts, models, and knowledge across the lifecycle. Again, both span the engineering lifecycle, so they are not suitable replacements for MBSE, but they wonderfully represent the greater engineering approach we seek to enable.

What then about “digital systems engineering”? It is a good attempt, but it leads to digitalization of systems engineering artifacts rather than emphasizing the rich interconnected nature of concepts necessary in the engineering of a system. As an analogy, Google maps is not digital maps. It is a rich amalgamation of data in a model built on a defined metamodel that allows multiple representations: a classic map, a satellite view, a street view, dynamic traffic loading, and more. Digital systems engineering would be lead us to digital specifications and diagrams rather that the real integrated model beneath.

It is time to move beyond our obsession with the terminology and instead emphasize intent, principles, and desired outcomes. It’s time to drop “model-based” and return the focus to systems engineering. We are on a continuous journey to improve the processes, methods, and tools that enable the practice of systems engineering. It doing so, we can embrace new structures to better elicit and capture knowledge, new ways to better frame, understand, and communicate both the problem and solution space. In dropping “model-based” but keeping systems engineering, we gain the richness and power of the underlying concepts without the accumulated baggage, misconceptions, and confusion that continue to slow our evolution.

If I could snap my fingers and make this so, I certainly would. That said, MBSE will continue to be the industry obsession – at least for several years to come. If so, then what? The wise practitioner looking to advance the state of the practice in their organization or across the community will use the language to start the dialog but then carefully clarify concepts, combat misconceptions, and maintain focus on the greater systems engineering principles and framework that underpin success.